Core principles in the Agile Manifesto take five minutes to read and a lifetime to understand — especially when applying them to the increasingly distributed team structures of today. Tenets like “software over documentation,” “responding to change over following a plan” and “quality interactions over tools” take on new meaning managing remote teams. How can teams maintain effective communication patterns when they are separated by two or more time zones?

Download: Highly Effective Habits of Agile Teams

Why Agile prioritizes communication

Agile methodology recognizes face-to-face communication as the most efficient and effective means to share ideas. The benefits of sketching on cards or a whiteboard are two-fold — increasing the level of understanding and decreasing the time it takes to deliver the message.

Most credit the adoption of Agile thinking as the primary driver to create more open, collaborative office spaces no longer punctuated by rows of cubes and team members emerging every so often. Open spaces led to more drive-by conversations between team members and more feedback gathered throughout the development process organically. More active information seeking leads to compressed timelines and better outcomes.

Unlike smaller teams who do have the option to co-locate, enterprises managing remote teams often don’t have the luxury of sharing the same physical space each day.

Team structure options:

[Easy]

The stakeholders and the development team share the same physical space.

[Medium]

The business is physically separated from the development team with the stakeholders in one office and the development team in another, often offshore.

[Difficult]

The stakeholders and the development team are separated by distance and time. Additionally, the development team itself is distributed across cities or countries.

Distributed teams must actively work to avoid falling into communication traps that shift project process away from Agile development to a decidedly waterfall one. But, the world is a small place even for distributed teams — made smaller by the host of available communication platforms from Slack to Jira to Skype. Encouraging the same close communication expectations is the key to upholding Agile process on distributed teams.

7 Agile communication strategies for managing remote teams

1. Foster a culture of continuous integration when builds are constantly discussed and planned.

Creating a culture where continuous integration is the norm is especially valuable on projects with extended timelines or when managing remote teams. In this structure, it’s easy to opt for dividing work for teams along technical boundaries. These technical boundaries may be divided by frontend/backend work or even database and services layer/frontend. Team bandwidth or security might drive the divisions. Additionally, some businesses may be wary of releasing intellectual property into a cloud-based platform like GitLab.

This often results in the maintenance of two source code repositories with a commitment to merge them later. Resist this. The technical debt that results from this fractured code is more time-consuming to overcome than if the teams had increased the communication necessary to maintain just one code repository in the first place. Overcoming any communication hurdles to work on the same code base is worth it in every way.

Team leads successful at managing remote teams and implementing this culture will even begin to see evidence manifest in the daily communication and behavior of team members:

• All members actively strive not to break the build.
• They will provide visibility to broken builds.
• All will react with a sense of urgency to adjust build issues.

2. Commit to regular builds, so you don’t prioritize upholding the plan over agility.

It’s easy to produce a giant spec in lieu of communicating daily with the offshore development team or let distance become a reason to stay the course and avoid evolving the solution when challenges or barriers arise.

Building on a weekly schedule is good, daily is even better. Hold your team accountable to submit a change set to the source code control each time. Then, take advantage of your compiler as a stand-in team member to ensure your source code has reached or exceeded quality expectations. Adding smoke tests can move this dial even further.

3. Embrace the social process of developing custom software.

Most people assume custom software development is a purely technical process. While it’s true the process is highly technical requiring years of training and experience to run successfully, software development is a social process first and relies on trust built between individuals.

Encourage knowledge sharing on every team. This is less about cataloging processes in a Wiki and more about cultivating this naturally in daily stand-ups or any time team members give updates.

Encourage your team to share beyond what pertains to that day’s work. If a team member anticipates something they are working on may impact another role the next day, call that out. Once team members master the habit of sharing meaningful, forward-looking insights to their work, that’s when true knowledge sharing has been achieved.

Get the eBook: The Complete Guide to Organizing and Leading Distributed Teams

4. Foster close communication between UX designers and business analysts to accelerate throughput by a factor of two.

Encouraging close collaboration between designers and business analysts, encouraging extra attention to the graphical interface. This may mean additional time is spent creating visual artifacts for the technical team to complement related user stories. The reward? Less questions related to aesthetics and fewer iterations created as a result of the mismatched expectations.

5. Discuss even non-functional requirements.

For teams who are co-located, it’s easy to address questions around performance and scalability as they arise. Conceptualizing and documenting requirements with the appropriate level of detail serves as the link between the business and technical teams.

For distributed teams, understanding non-functional requirement detail plays an even larger role. Without explicit directions documented for the technical team, it might result in the creation of an architecture that makes assumptions about the non-functional requirements resulting in increased rework, time and spend later.

6. Managing a distributed team may mean documenting more.

While all Agile teams strive to write “just enough” requirements, managing a distributed team means accepting “just enough” may still mean documenting more than would be created for a co-located team.

Distributed team members can’t quickly sketch on a whiteboard to work through a complex concept. Rather than leaving your development and testing teams left guessing on the nuances that would otherwise be delivered verbally, document them and “give the answers” before the test.

By augmenting user stories with test or acceptance criteria you can set the technical team up for success without drastically expanding the narrative.

7. Choose a suite of communication tools for your team that allows for the natural escalation of communication needs.

When teams are co-located, the level of communication needed escalates naturally. It might begin with co-workers speaking one-to-one in the breakroom. If clarifying details are needed, additional subject matter experts may be pulled into the conversation. Then, the conversation shifts from many-to-one or many-to-many, depending on the context. Maintaining this escalation process is essential to create outlets for quick answers or more in-depth conversations despite any distance that may exist between team members.

Communication escalation

• Chat 1–1
• Chat many-to-1
• Voice call
• Visual call
• Screen share
• Collaborative composition

The ability to ask quick clarifying questions is ingrained in how most teams work. In the past, this could be accomplished with face-to-face drive-bys in the office. But, increasingly even teams who are co-located are relying on instant messenger to accomplish this.

Instant messaging is a powerful tool for managing remote teams that include non-native English speakers. The medium affords them the space to craft responses without the pressure of discussing directly (and quickly) with a native English speaker. That said, tools like Slack allow for escalation from messaging to voice and video calls and even screen sharing if needed.

While the importance of instant messaging cannot be over-emphasized for distributed teams, observing body language and physical reactions to statements or questions are also critically important, especially when discussing challenges or questions to gauge feasibility or understanding.

What does it take to succeed with distributed Agile software teams?

No electronic tool or communication strategy can replace the perseverance of the leaders required to realize their potential. These leaders must believe Agile can work for distributed teams. If they do, it will.

Innovate with us. Click here to access all of our free resources.

Authored by Jamie Bolseth and Emily Genco.